REMARKS 

Applicants respectfully traverse and request reconsideration. 

The Disclosure stands objected to because of various informalities. As requested, 
amendments to the Specification have been made and submitted herein. 

Similarly, informalities in Figure 5, 6 and 1 1 have been corrected. The cited 
informalities include typographical and format errors. A final copy and a red-lined copy of 
Figures 5, 6 and 1 1 are provided herein for Examiner's approval. 

Claims 1, 7, 14, 15 and 17 stand objected to because of various informalities. Addressing 
the Examiner's request, Applicants have appropriately amended the claims as indicated herein. 

Claim 1 has been cancelled, and new Claim 22 has been submitted for examination. In 
particular, Claim 22 indicates that the data storage controller has a first input port coupled to the 
first output port of the transport stream interface control to accept the set of control signals of the 
transport stream interface control, a second input port coupled to the second output port of the 
transport stream interface control to accept video graphics data, an output address port to provide 
an address value, an output video data port to provide video data, and at least one pair of a 
plurality of internal control ports to communicate control signals within the data storage 
controller. (Figure 3; Page 6, Line 27-Page 7, Line 1; Page 8, Lines 7-8; Page 10, Lines 3-4, 9- 
10; Page 13, Lines 7-8; Page 15, Lines 21-23). 

Claims 2 and 6 have been amended to reflect their dependence upon new Claim 22. 
Furthermore, Claim 2 has been amended to reflect that the system of Claim 22 further comprises 
a memory having a first port coupled to the output video data port of the data storage controller 
and a second port coupled to the address port of the data storage controller. 

Claims 4 and 5 have been amended to correct various informalities and reflect proper 
dependence upon Claims 22 and 2. 

Claim 7 stands rejected under 35 U.S.C. § 1 12, 2d paragraph, as being indefinite for 
failing to particularly point out and directly claim the subject matter which Applicants regard as 
the invention. Claim 7 has been amended such that it now contains only a single sentence in 
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accordance with proper claim format. New Claim 22 has been added to depend upon Claim 7 
and indicate that the control signals of the digital video transport stream may further include an 
error signal, indicating there is an error in the transport stream. 

Claim 10 has been amended to correct a typographical error. Claims 14-17 have been 
amended to correct various informalities. 

Applicants respectfully note that the amendments to the claims are not narrowing 
amendments and they do not add new subject matter. The set of amendments include patentable 
subject matter inherently found within the Application as filed. If the Patent Office is of a 
different opinion, Applicants respectfully request the Examiner to contact the Applicants' 
attorney. 

Claims 14 and 18-20 stand rejected under 35 U.S.C. § 102(e) as being anticipated by 
Chauvel, et al. 5 U.S. Patent No. 6,369,855 ("Chauvel"). Chauvel is directed at an audio and 
video decoder circuit and system. Figure 1 A depicts a high level layout of a communication 
system in accordance with the Chauvel reference. In particular, received satellite signals are 
intercepted by a satellite reception dish (Element 5), provided to a tuner (Element 20) via a low 
noise amplifier. The tuner selects the signals the user wishes to watch and passes the desired 
signals to a quadrature phase-shifting keying (QPSK) circuit (Element 30) that recovers the 
digital data in the selected signal. After the data passes an error correction unit (Element 40), the 
corrected received data is passed to an integrated circuit (Element 200) where packets of data are 
parsed and converted to proper form prior to display. In particular, the circuit parses packets of 
data and converts the data to video, audio and On Screen Display (OSD) signals, which maybe 
appropriately displayed on audio visual display, on an NTSC/PAL television, or converted for 
display on other types of televisions (Figures 1 A; Col. 8, Lines 38-58). In summary, the Chauvel 
reference appears to be directed at a different system and method of an audio video decoder and 
not a video graphics system as claimed by Applicants. 

With respect to Claim 14, the Applicants respectfully believe the Examiner's citation to 
Chauvel as teaching the limitations of the Applicants' claimed invention is improper. The 
Applicants respectfully reject the Examiner's citation to Chauvel, Col. 8, Lines 45-47, as 
teaching a transport stream having data signals and control signals. Instead this reference 
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teaches a tuner in accordance with Figure 1 A that is connected to a quadrature phase-shifting 
keying circuit that recovers digital data in a selected signal. Such a selected signal corresponds 
to the signal a user wishes to watch. (Col 8, Lines 44-45). Furthermore, the Applicants contest 
the Examiner's citation to Chauvel, Col. 9, Lines 1 1-1 3, as teaching the reception of a transport 
stream associated with a digital video broadcast signal, the transport stream having data signals 
and control signals as taught by the Applicants. (Emphasis added). The Examiner's cited 
reference teaches the many components of the integrated circuit (Element 200) of Figure 1 A. In 
particular, Figures IB and 2 of Chauvel show a transport packet parser clock (Element 210) that 
includes a bit stream decoder or descrambler and a clock recovery circuitry. Accepting a 
transport bit stream from the output of a forward error correction device, the transport packet 
parser processes the header of each packet and determines whether the packet should be 
discarded, further processed by ARM CPU (Element 220), or if the packet contains relevant data 
and may be stored without any intervention from the ARM. (Col. 10, Lines 9-18). In contrast, 
the Applicants teach control signals that may include a multi-bit data signal (DATA), a 
synchronization signal (SYNCH), a data valid signal (DVALID), and a clock signal (TCK). 
(Page 6, Lines 22-23). 

Citing Element 3 10 in Figure IB, the Examiner appears to have improperly referenced 
the traffic controller of Chauvel as disclosing the Applicants' step of generating a secondary set 
of control signals from a transport streams control signals. In contrast, Chauvel teaches a system 
and method in which the traffic controller repacks data processed by the ARM CPU (Element 
220) and removes the voids created by any header deletion by the transport packet parser 
(Element 210; Col. 10, Lines 39-40); manages two physical DMA channels to facilitate large 
block transfers between memory and buffers (Col. 12, Lines 15-20); and manages interrupt 
requests and authorizes and manages DMA transfers, providing SDRAM interface and manages 
the extension bus (Element 300). (Col. 18, Line 66-Col. 19, Line 2). Applicants respectfully 
submit that the traffic controller element of Figure IB fails to disclose the claimed step of 
generating a secondary set of control signals from the transport stream control signals as taught 
in the Applicants' Specification. The Specification teaches that the video-in-controller (Element 
510) acts as a stream interface control to convert the received signal, whether zoom video or a 
transport stream, into a Start of Field (SOF) signal, a Start of Active (SOA), and End of Active 
(EOA) signal, a Data Active (D ACTIVE), and a Video Data (VDATA) signal. The 
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Specification further teaches that such signals are provided to indicate the start of new frames 
and new lines within a frame as indicated in Figure 6. 

The Examiner further cites Figure 18B as teaching the Applicants' step of storing at least 
a portion of the transport stream data signals in the memory buffer controlled by the secondary 
set of control signals. Specifically, the Examiner cited buffer Element 3 12A and memory 
interface Element 313. Figure 18B shows how the OSD unit (Element 270) may be employed to 
provide OSD with a variable resolution. In particular Figure 18B shows the global flow to 
decode and display an OSD picture. In contrast to the Applicants claimed invention, the OSD 
controller (Element 270) reads the OSD buffer (Element 3 12B) and generates the OSD video that 
is mixed with MPEG video. In particular, the PSI buffer (Element 312A) contains a coded 
picture for display within an OSD picture. (Col. 41, Lines 30-40). The memory interface and 
buffer of ChauvePs Figure 18B (Elements 313 and 312a, respectively) do not appear to teach the 
Applicants' claimed step of storing at least a portion of the transport stream data signals in a 
memory buffer controlled by the secondary set of control signals as referenced in Applicants' 
Figure 5 at label VIDEO DATA and in Applicants' flow diagram of Figure 1 1 at step 1 105. 
(Emphasis added). 

The Examiner cites the coupling of the traffic controller (Element 310) and the system 
bus (Element 330) of Figure IB as showing the Applicants' step of sending the contents of the 
memory buffer to a system bus. Applicants respectfully repeat the relevant remarks made above 
in reference to the functionality of Chauvel's traffic controller. In particular, the Applicants 
emphasize that the traffic controller does not perform the step of generating a secondary set of 
control signals, such as SOF, SO A and EOA, from the transport stream's control signals as 
taught by Applicants. In light of the above remarks, Chauvel fails to anticipate the claimed 
invention of Applicants. Claim 14 is in proper condition for allowance. 

With respect to Claims 18-20, the Applicants respectfully reference Figures 1 and 2. 
Figure 1 displays a prior art system; Figure 2 corresponds to the Applicants' claimed invention. 
As taught in the Specification, the prior art system of Figure 1, relied upon a converter/PCI 
bridge to change the transport stream into data packets capable of being transmitted across a 
system bus, such as through the PCI bridge. Such a conversion would require converting the 
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188-byte packet of the transport stream into 32-bit or 64-bit wide words of information and 
transporting the words to memory or the video adapter across the PCI bus. (Page 2, Lines 12- 
19). As an immediate result of the converter/PCI bridge, the prior art system suffered from 
increased costs and high consumption of bandwidth, thereby limiting system resources. In 
Applicants' claimed invention a video graphics adapter is coupled to receive the transport stream 
without the utilization of a converter/PCI bridge. 

To the extent that any comparison can be made between the Chauvel reference and the 
Applicants' claimed invention, Chauvel is most similar to the prior art system as illustrated by 
Applicants' Figure 1. The Chauvel reference contains a transport packet parser ("TPP;" FIG. 
IB, Element 210) that includes a bit stream decoder or descrambler (Element 212) which receive 
"a high speed bit stream and directs the data to the right destination. The TPP discards packets 
not selected by an application and routes as many packets as possible without real-time help 
from either the ARM CPU 220 or software running on the ARM CPU." (Col. 9, Lines 30-43). 
Such a device is not required in the Applicants' Claim 18. Rather, the transport stream is 
directed to the video graphics adapter as illustrated in Applicants' Figures 2, 4 and 5. The 
Applicants respectfully believe that Claim 18 is in proper condition for allowance. 

Claims 19-20 add further patentable subject matter and are believed to be in condition for 
allowance. 

Claims 1-10 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Chauvel. 
The Applicants respectfully repeat the relevant remarks made above with respect to Claim 14. 
Claim 1 has been cancelled without prejudice. Applicants submit new Claim 22 for examination. 
In contrast to the Examiner's characterization of Chauvel, the video graphics system of Claim 22 
is not made obvious by the audio and video decoding circuit and system of Chauvel. As 
submitted above, the Chauvel reference remains silent as to a transport stream port to receive a 
digital video transport stream where the digital video transport stream includes a data stream and 
control signals. Furthermore, Chauvel fails to teach a system in which a new set of control 
signals are provided from a transport stream interface control. Said set of signals may include, 
inter alia, a Start of Field (SOF) signal, a Start of Active (SOA), and End of Active (EOA) 
signal, a Data Active (D ACTIVE), and a Video Data (VDATA) signal. Moreover, Chauvel does 



CHICAGO/A 1023554.1 



27 



not disclose a data storage controller operatively coupled to the transport stream interface control 
with output ports capable of providing an address value and video data, and internal control ports 
communicating control signals within the data storage controller. Applicants' Figure 5 
corresponds to the limitations of Claim 22. As taught in the Applicants' Specification, the data 
storage controller comprises the window controller (Element 520), the address generator 
(Element 530) and the packer (Element 540) working together. (Page 15, Lines 21-23). 

Addressing the Examiner's additional citations to Chauvel, Applicants respectfully note 
that the TPP (FIG. IB, Element 210) is not analogous to the transport stream interface control of 
the Applicants' claimed invention. While the TPP analyses the bit stream, discards packets not 
selected by an application, and routes as many packets as possible, the transport stream interface 
control can be best understood with reference to Applicants' Figure 5. Specifically, the video-in 
controller (Element 510) acts as a stream interface control to convert the received signal into a 
set of control signals (SOF, SO A, EOA, and DACTIVE) and video graphics data (VDATA). 
(Page 6, Line 27- Page 7, Line 1). 

Furthermore, Applicants respectfully note that the output address port of the data storage 
controller does not appear to be taught by the Chauvel' s connection of the traffic controller and 
the bus of Chauvel's FIG. IB (Elements 310 and 330, respectively). In contrast, the internal 32- 
bit data bus (Element 330) is utilized to connect the various block modules within the audio and 
video decoding circuit (Element 200). As described above, the traffic controller (Element 310) 
repacks data processed by the ARM CPU (Element 220) and gets rid of the voids created by any 
header removal by the transport packet parser (Element 210; Col. 10, Lines 39-40); manages two 
physical DMA channels to facilitate large block transfers between memory and buffers (Col. 12, 
Lines 15-20); and manages interrupt requests and authorizes and manages DMA transfers, 
providing SDRAM interface and manages the extension bus (Element 300). (Col. 18, Line 66- 
Col. 19, Line 2). 

While Chauvel does not disclose a sequence of port as claimed; specifically, the labeling 
of input and output ports with numerical values, the Applicants submit that the port distinctions 
are further patentable material in addition to the unique limitations of Applicants' Claim 22 not 
disclosed by Chauvel. The Applicants' respectfully challenge the Examiner's statement that it 
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would have been obvious to one of ordinary skill in the art at the time the invention was made to 
configure the ports as necessary for the video graphics system. Specifically, the Applicants 
respectfully request a showing of prior art properly combinable with the audio video decoder of 
Chauvel that would make obvious the invention of Claim 22. 

With respect to Claim 2, the Applicants respectfully repeat the relevant remarks made 
above in regard to Claim 22. Furthermore, the Applicants respectfully note that as Claim 2 
inherits the limitations as set forth in Claim 22, the video graphics system of Claim 2 further 
comprises patentable distinctions with respect to the Chauvel reference. Specifically, Chauvel is 
silent as to a memory operatively coupled to the video graphics system of Claim 22. The 
Applicants respectfully believe that Claim 2 is in proper condition for allowance. 

Claims 3-10 and new Claim 23 inherit the claimed limitations of new Claim 22. 
Applicants respectfully repeat the relevant remarks made above with respect to Claim 22 and 2, 
and submit that Claims 3-10 further contain patentable subject matter not made obvious by 
Chauvel. Specifically, the Applicants respectfully challenge the Examiner's statements that the 
claimed invention of Claims 4, 5, 9 and 10 that it would have been obvious to one of ordinary 
skill in the art to configure the ports as necessary for the desired functionality of the claimed 
video graphics adapter. The Applicants respectfully request a showing of prior art that would 
provide such motivation. 

With respect to Claim 8, the Applicants respectfully challenge the Examiner's suggestion 
that Chauvel discloses a set of control signals of the transport stream interface control that 
includes a start of field signal to indicate the start of a frame of video in Col. 12, Lines 56-58. In 
contrast this reference merely states that "[t]he digital output provides video in either 4:4:4 or 
4:2:2 component format, plus the aspect ration VARIS code at the beginning of each vide 
frame." In contrast to Applicants' claimed invention, this reference gives the ration of the 
image's width and height. 

In regard to Claim 9, the Applicants respectfully repeat the relevant remarks made above 
and further note Applicants have previously established that the transport stream interface 
control is not analogous to the traffic controller (FIG. IB, Element 313). As a result the 
Data Valid signal of Chauvel's Figure 16S does not make obvious the use of control signals that 
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include a valid data output to indicate when data on the second output port of the transport 
stream control is active video data. 

The Examiner has cited Chauvel's Col. 1 10, Lines 15-16 as disclosing the Applicants' set 
of control signals of the data storage controller that includes a valid vertical blanking interval 
signal to indicate when data on the second output port of the transport stream interface control is 
present during a vertical blanking interval. However, Applicants respectfully note that the VBI 
bits disclosed in Chauvel requires the use of an encoder (Col. 110, Lines 9-10). The use of an 
encoder is not required in the Applicants' claimed invention. 

In light of the above remarks, the Applicants respectfully believe that the Chauvel 
reference teaches away from the Applicants' claimed invention. Claims 22, 2-10 and 23 are 
believed to be in proper condition for allowance. 

Claims 11-13 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Chauvel as applied to Claim 6 above and further in view of Baker, U.S. Patent No. 6,333,938 
("Baker"). 

Applicants respectfully repeat the relevant remarks made above with respect to Claims 6 
and 22. Furthermore, Applicants respectfully challenge the Examiner's suggestion that the front 
panel (FIG. IB, Element 300-4) may be used as a select node. The Applicants are confused as to 
how the front panel, one of seven internally generated chip selects each with its own defined 
memory space and a programmable wait state register, discloses a select node as taught by 
Applicants. As one of the chip selects, the front panel allows the extension bus to connect to an 
additional device for external decoding. (Col. 15, Lines 9-41). The Applicants' attorney 
respectfully requests clarification as to the manner in which said front panel may serve as a select 
node coupled to a transport stream interface control and to a first video interface control. 

The Baker reference is directed to a method and system for extracting control information 
from packetized data received by a communications interface device. More specifically, the 
invention is directed at separating the header portion from the video data portion in data packets 
and then directing the video data portion into a zoom port. (See Abstract). While Baker 
discloses a port operative to receive various types of data from peripheral devices (FIG. 1 5 
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Elements 18 and 14), Baker fails to disclose a select node coupled to the transport stream 
interface control and to the first video interface control. The Examiner's suggestion that user 
defined function unit (FIG. 1, Element 40) discloses said select node is respectfully challenged. 
Applicants note that said user defined function unit can be compared to similar PROM, SPRAM 
and other RAM-like devices that appear in Figure 1 . In reference to Figure 2 5 "local bus 
interface logic 70 supports PCI slave and internal DMA read/write access to devices such as 
flask PROM, SPRAM and other RAM-like devices." (Col. 7, Lines 50-67). In contrast to 
Baker, Applicants do no claim such a user defined function unit similar to RAM-like devices 
controlled through local bus interface logic. 

Moreover, the Applicants challenge the motivation to combine Chauvel and Baker. Both 
references are directed at distinctly different subject matter. Applicants respectfully believe that 
the objection to Claim 1 1 is no more than impermissible hindsight analysis. Per M.P.E.P. § 
2142, the conclusion of obviousness "must be reached on the basis of facts gleaned from the 
prior art." That is, a conclusion of obviousness is proper "so long as it takes into account only 
knowledge which was in the level of ordinary skill in the art . . . and does not include knowledge 
gleaned only from Applicants' disclosure ... (M.P.E.P. § 2145(X)(A)). In the instant case, the 
only apparent source of a teaching the limitations of Claim 1 1 are the instant Application. 
Applicants respectfully believe Claim 1 1 is in proper condition for allowance. 

Claims 12 and 13 depend upon allowable Claim 1 1 and further contain patentable subject 
matter. Applicants respectfully note that the Examiner rejected Claim 1 1 on the basis that Baker 
teaching a first video port to receive digital video of a first type via the three-port physical layer 
interface and interface device. (FIG. 1, Elements 18 and 20, respectively). Relating to Claim 12, 
Applicants are confused as to the Examiner's suggestion that a separate unit internal to the 
personal computer (FIG. 1, Element 12) can be cited as teaching the limitation that the first video 
port is a zoom video port. Specifically, the Examiner cited ZV Port (Element 42) coupled to the 
PCI-Serial bus interface via an AUX port local bus as teaching the limitation of Claim 12. 
Applicants note that the ZV Port cannot serve as a specific embodiment of the three-port 
physical layer interface when the two units are two individual, distinct and separate units with 
different functions. Similar to the user defined function block (Element 38), the ZV Port is 
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operable based upon local bus interface logic (FIG. 2, Element 70). Applicants respectfully 
believe Claims 1 1-13 are in proper condition for allowance. 

Claims 15-17 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Chauvel as applied to Claim 14 and further in view of Baker. Applicants respectfully repeat the 
relevant remarks made above with respect to Claim 14 note that Claims 15-17 contain further 
patentable subject matter. Moreover, the Applicants repeat the relevant remarks made with 
respect to Claims 1 1 and 12. Claims 15 and 16 correspond to the method claims of Claims 1 1 
and 12. Applicants respectfully believe that Claims 15-17 are in proper condition for allowance. 

Claim 21 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over Flurry, 
U.S. Patent No. 5,898,441 ("Flurry"). Flurry is directed at a method and apparatus for 
processing video data including multiple frames of image data in a first format. This method 
includes storing the video data in a first memory location, and converting a first potion of the 
multiple frames stored in the first memory location into a second format for storage in a second 
memory location, while concurrently converting a second portion of the multiple frames stored 
in the first memory location into a third format for display on a display unit. (See Abstract). 
Specifically, the system is provided to support multiple users of graphics and video adapters and 
further supports the integration of video capture and monitoring of the captured video in a multi- 
user environment. (Col. 2, Lines 30-40). 

However, Flurry fails to teach the limitations of Claim 21 as there is no reference to two 
modes of operation wherein one mode, one line of frame buffer memory (comprising pixel 
information) is representative of one line of a video image to be displayed, and in a second mode 
of operation, one line of frame buffer memory (comprising compressed transport stream data) is 
representative of one line of one transport stream packet. While Flurry teaches the integration of 
video capture and monitoring of captured video in a multi-user environment via the above- 
mentioned steps, Applicants teach a system and method wherein a video graphics adapter can 
accept either compressed data (transport stream data) or uncompressed data (such as zoom 
video), determine the proper mode of operation, and process the stored information as submitted 
in Claim 21. 
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The Examiner cited Flurry, Col. 5, Lines 30-42, as teaching the limitations of Claim 21; 
Applications respectfully challenge this rejections and believe it to be improper. The cited 
reference merely teaches that the frame buffer (FIG. 4, Element 240) of Flurry includes both a 
visible portion (Element 400) and an invisible portion (Element 405). The visible portion of the 
frame buffer includes pixel information for each of the display pixels. No reference is made to a 
the Applicants' claimed invention wherein one line of frame buffer memory is representative of 
one line of a video image to be displayed. Instead, the reference teaches that the visible portion 
of the frame buffer corresponds to the section that the Look Up Table ("LUT;" FIG. 1, Element 
245) reads for converting digital data for display. Furthermore, the reference teaches that the 
invisible portion is used for the temporary storage of images in a variety of formats and sizes and 
are available for scaling, conversion, or other operations. For example, if a large YUV-type 
image needed to be displayed on a smaller window and converted to RGB-format, the image 
could be converted and scaled to the proper size and desired format by the video processor and 
stored in the visible portion of the frame buffer. 

Flurry is silent as the teaching two modes of operation; the first mode indicating that 
pixel information is stored in a frame buffer, while the second mode indicating that compressed 
transport stream data is stored in a frame buffer. Flurry fails to disclose the correspondence 
between a line of frame buffer memory and one line of a video image to be displayed (during the 
first mode of operation) or one transport stream packet (during a second mode of operation). As 
such, Applicants respectfully believe Claim 21 to be in proper condition for allowance. 

Attached hereto is a marked-up version of the changes made to the Claims by the current 
amendment. The attached page is captioned "Version with markings to show changes made." 
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Accordingly, Applicants respectfully submit that the claims are in condition for 
allowance and that a timely Notice of Allowance be issued in this case. The Examiner is invited 
to contact the below-listed attorney if the Examiner believes that a telephone conference will 
advance the prosecution of this application. 



VEDDER, PRICE, KAUFMAN & 

KAMMHOLZ 

222 N. LaSalle Street 

Chicago, IL 60601 

(312) 609-7500 

FAX: (312)609-5005 
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Respectfully submitted, 



Date: 




By: 




VERSION WITH MARKINGS TO SHOW CHANGES MADE 



In the Specification : 

Please replace the paragraph beginning at page 2, line 10 with the following rewritten 
paragraph: 

Also illustrated in the prior art of Figure 1 is a Peripheral Component Interconnect (PCI) 
[Bus]bus supporting conventional computer-type peripherals. Connected to the PCI [Bus]bus of 
Figure 1 are a [Memory, a central] memory, a Central Processor Unit (CPU), and a [Video 
Adapter] video adapter . In order to support the reception and subsequent transmission of the 
transport stream to one of the system components, such as to the [Memory] memory or the 
[Video Adapter, a Converter/PCI Bridge] video adapter, a converter/PCI bridge has been used. 
The converter portion is necessary in order to change the transport stream into data packets 
capable of being transmitted across a system bus, such as through the PCI bridge. Such a 
conversion would require converting the 188-byte packet of the transport stream into 32-bit or 
64-bit wide words of information and transporting the words to [Memory] memory or the [Video 
Adapter] video adapter across the PCI [Bus]bus. 

Please replace the paragraph beginning at page 2, line 20 with the following rewritten 
paragraph: 

In order to provide data to the video adapter of the prior art, it is necessary for separate 
printed circuit boards to be used to implement the transport stream converter and video adapter. 
Separate boards [allows] allow a PCI interface to the video memory associated with the video 
adapter. Separate board increase overall system costs. In addition to increasing overall system 
costs, the data stream [data] requires approximately 5 Mbytes of PCI bandwidth, thereby limiting 
the bandwidth available to other system resources. In addition, when analog video is received 
and digitized (not illustrated),_by the prior art system the PCI band data bandwidth is 
approximately 25 Mbytes. 

Please replace the paragraph beginning at page 2, line 28 with the following rewritten 
paragraph: 
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Another proposed method for receiving DVB data was to use the side port of a video 
graphics adapter in order to receive the transport stream information. However, the video side 
port is designed to only receive uncompressed digital video instead of compressed MPEG 
transport stream. A format conversion chip is needed between the DVB demodulator output and 
video side port to convert a transport stream into a compatible ITU-656 ancillary stream (digital 
video or data format) like format. This will add cost to system implementation. Another problem 
is that the data in the transport stream is not fully compliant with ITU-656 data, ([values] Values 
such as 00 and FF are not allowed in an ITU-656 stream but allowed in a transport stream. So 
this implementation cannot work if the video side port is strictly designed for ITU-656 data 
streams.) 

Please replace the paragraph beginning at page 4, line 5 with the following rewritten 
paragraph: 

A method and apparatus for receiving one of a compressed video stream and an 
uncompressed video stream is disclosed. The uncompressed video stream may be [Zoom 
Video] ZOOM VIDEO data or a digitized analog video signal. The compressed video stream 
may be an MPEG [transport stream] TRANSPORT STREAM data from a High Definition 
[television] Television (HDTV) broadcast. A [Video Graphics Adapter] video graphics adapter is 
configured to properly receive one of the two types of video data. The received data and control 
signals are monitored to provide a second set of control signals that are used by a packer, a 
window [control] controller , and an address generator. The packer packs data into a format 
which is compatible with the frame buffer memory. The window controller controls the amount 
of data written into frame buffer memory. The address generator generates proper frame buffer 
addresses for the data. The data is stored within a pre-defined area of graphics memory such as a 
frame buffer. The data can be transferred to system memory when a buffer is full. 

Please replace the paragraph beginning at page 4, line 16 with the following rewritten 
paragraph: 

Figure 2 illustrates a system in accordance with the present invention. A digital video 
broadcast (DVB) signal is received by the tuner 210. The tuner 210 provides a representation of 
the received analog signal to the demodulator 220. The demodulator 220 demodulates the signal 
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to provide a digital TRANSPORT STREAM to one or both of the [Transport 
Demultiplexor] transport demultiplexor 240[,] and the [Video Adapter] video adapter 230. In 
accordance with the present invention, the [Video Adapterl video adapter 230 receives the 
TRANSPORT STREAM and buffers it into a video memory, or frame buffer. Upon filling the 
frame buffer, the [transport stream] TRANSPORT STREAM data is either further utilized by the 
[Video Adapter] videoadapter 230, or at least partially provided to system components, such as 
the [central processing unit] Central ProcessinR Unit (CPU) 250, or the memory 260. A second 
data path receives an analog signal, such as would normally be associated with television 
broadcasts, at tuner 21 1 . The signal from tuner 21 1 is provided to a NTSC/PAL/SECAM 
demodulator 221 to provide a digital representation of the received analog signal. [Notj Note that 
the tuner 21 1 and demodulator 221 may be the same, or different, from the tuner 210 and 
demodulator [2111220. 

Please replace the paragraph beginning at page 5, line 1 with the following rewritten 
paragraph: 

Figure 3 illustrates the [Video Adapter] video adapter 230 in greater detail. In normal 
operation, the [Video Adapter] videoadapter 230 processes video and/or graphics information 
and provides a signal labeled VIDEO OUT. The VIDEO OUT signal is used to drive an image 
onto an external display device (not shown). In accordance with the present invention, the 
[Video Adapter] video adapter 230 includes a [Capture Block] capture block 310 to receive a data 
stream, a graphics engine 320, a graphics memory [231] 330, and a PCI interface 340. 

Please replace the paragraph beginning at page 5, line 10 with the following rewritten 
paragraph: 

In operation, the [a] digital data stream, such as the TRANSPORT STREAM from the 

demodulator 220 of Figure 2, is received at the capture block 310. Where the digital data stream 
is a TRANSPORT STREAM, the TRANSPORT STREAM comprises both data[,] and control 
information. Generally, the TRANSPORT STREAM includes a plurality of packets. Each 
packet of [transport stream] TRANSPORT STREAM information includes a synchronization 
byte followed by a predetermined number of data bytes. The data bytes can include routing 
information stored as header information, or as raw data as identified by the header information. 
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When the data is transmitted as header information, it is in an uncompressed form that indicates 
the type of data that is to follow the header. A single header can be included in one or more 
packets. 

Please replace the paragraph beginning at page 5, line 16 with the following rewritten 
paragraph: 

The [Capture Blockl capture block 310 receives the TRANSPORT STREAM information 
and provides the necessary data and control in order to store the compressed [transport 
stream] TRANSPORT STREAM data within the [Graphics Memory] graphics memory 330. The 
memory 330 is accessed over the bus 350. In a specific embodiment, the memory 330 is a frame 
buffer used by the [Graphics Engine] graphics engine 320. The [Memory] memory 330 is 
connected to the [Capture Block] capture block 310 through the bus 350 which accommodates 
the necessary data, address, and control lines for accessing memory 330. The graphics memory 
330 is also connected to the graphics engine 320 and the PCI Interface 340 through the bus 350. 

Please replace the paragraph beginning at page 5, line 23 with the following rewritten 
paragraph: 

In accordance with the present invention, the graphics [Memory] memory 330 can operate 
as a frame buffer for the [Graphics Engine] graphics engine 320, or as a buffer to store the 
TRANSPORT STREAM data. The PCI Interface 340 provides an interface between the internal 
bus 350 to an external PCI bus. Generally, the PCI Bus will be a system bus. It should be noted 
that while a PCI interface 340 has been shown, the present invention anticipates the use of other 
type bus interfaces. Therefore, the PCI interface 340 may be any bus type whether an industry 
standard or a proprietary interface. 

Please replace the paragraph beginning at page 6, line 1 with the following rewritten 
paragraph: 

Figure 4 illustrates the capture block 310 in greater detail. Specifically, the capture block 
3 10 is shown to receive a number of different types of video data. As indicated, 8-bit DVS 
(Digital Video Stream) video and ZOOM VIDEO is received. Generally, the 8-bit DVS and 
ZOOM VIDEO data are ITU-601 or ITU-656 related digital video streams. These streams are 
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1 not compressed video streams. However, the HDTV [transport stream] TRANSPORT STREAM 
received by the capture block 310 of Figure 4, as previously mentioned, is a compressed video 
stream, such as MPEG 2. While the DVS ? ZOOM VIDEO and TRANSPORT STREAM are 
illustrated in Figure 4 separately, in operation, the signals will share inputs that can be 
multiplexed, or de-multiplexed as needed. For example, the data bits from each format can be 
received by a common set of pins 

Please replace the paragraph beginning at page 6, line 10 with the following rewritten 
paragraph: 

A signal labeled VIDEO SELECT is used to indicate to the Capture Block 310, which 
type of video is to be received. By allowing for one of a plurality of types of digital video data to 
be received, greater flexibility is realized within the [video graphics adapter"| Video Graphics 
Adapter (VGA). This reuse of common circuitry allows for an efficient implementation of the 
present invention. Yet another advantage of the system as illustrated in [Figures] Figure 3 is that 
it reduces system costs over the prior art in that the PCI interface 340 already residing within the 
VGA is used to store transport buffered stream data. 

Please replace the paragraph beginning at page 6, line 20 with the following rewritten 
paragraph: 

In Figure 5, the TRANSPORT STREAM, and any other type of digital video, such as 
ZOOM VIDEO, is received by the [Video-In Controller] video-in controller 5 1 0 of Figure 5. The 
TRANSPORT STREAM includes the signals 501, which include a multi-bit data signal 
(DATA), a synchronization signal (SYNCH), a data valid signal (D VALID), and a clock signal 
(TCK). The ZOOM VIDEO data is illustrated as a bus. However, it should be noted, that the 
signals 501 can be multiplexed and/or de-multiplexed (not shown) to receive either ZOOM 
VIDEO or TRANSPORT STREAM data. 

Please replace the paragraph beginning at page 6, line 27 with the following rewritten 
paragraph: 

The [Video-In Controller] video-in controller 510 acts as a stream interface control to 
convert the received signal, whether ZOOM VIDEO or a TRANSPORT STREAM, into a Start 
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4 of Field (SOF) signal, a Start of Active (SOA) signal, an End of Active (EOA) signal, a Data 
Active (D ACTIVE) signal, and a Video Data (VDATA) signal. For ZOOM video, these signals 
are represented in Figures 6 and 7. 

Please replace the paragraph beginning at page 7, line 3 with the following rewritten 
paragraph: 

Figure 6 represents a frame of video 610. In a specific embodiment, the video is 
representative of ZOOM VIDEO. The frame of video 610 has a Vertical Blanking Interval 
(VBI) which resides in the first few lines of video. The VBI information is not displayed, but 
can be used to provide data for other operations of functions. Following the VBI portion, 
VIDEO is provided. Within the VIDEO portion, an [Active Video] active video 620 is illustrated 
which represents a portion of the VIDEO to actually be displayed. At the beginning of each line 
of the frame 610, a Start of Active (SOA) pulse is provided. At the end of each line of the frame 
610, an End of Active [video] (EOA) video signal is provided. At the beginning the first line of 
the frame 610, the start of a new frame is indicated by a Start of Frame (SOF) indicator. Note 
that the SOA and EOA refers to the [active video relative to the ZOOM VIDEO standard which 
is the] entire VIDEO portion [is considered active video] relative to the transmitted data. The 
[Active Video] active video 620 is the [Active Video] active video relative to the user. 

Please replace the paragraph beginning at page 7, line 15 with the following rewritten 
paragraph: 

The [Active Video] active video 620 of Figure 6 indicates the portion of the received 
VIDEO to be displayed. One example of the [Active Video] active video 620 varying from the 
received VIDEO is when the received video to be displayed on a standard television is High 
Definition Television (HDTV), which has a different aspect ratio than standard television, [is to 
be displayed on a standard television]. In this mode of operation, it is desirable to select only a 
portion of the HDTV frame for display on a standard television screen. In order to specify the 
desired [Active Video] active video 620, it is necessary to specify a Y OFFSET indicated where 
the first line of [Active Video] active video 620 begins, a X OFFSET indicating which pixel is 
the first pixel of [Active Video] activevideo 620, a WIDTH indicating the number of pixels in a 
containing [Active Video] active video 620, and a HEIGHT indicating the number of lines 
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containing the active [Video]\ddeo. Note that the X OFFSET, and Y OFFSET are illustrated to 
be relative to the first line and pixel of the frame 610. However, in other embodiments, other 
reference locations can be indicated. 

Please replace the paragraph beginning at page 7, line 26 with the following rewritten 
paragraph: 

Figure 7 illustrates the signals associated with ZOOM VIDEO. The ZOOM VIDEO 
signals received by the [Video-In Controllerl video-in controller 510 are substantially similar to 
the signals provided by the [Video-In Controllerl video-in controller 510, except that no 
DACTIVE signal is received. Therefore, since there is no equivalent signal to DACTIVE in 
[Zoom videol ZOOM VIDEO , the DACTIVE signal from video-in controller 510 specified is 
asserted when the [Video-In Controller] video-in controller 510 receives data. 

Please replace the paragraph beginning at page 8, line 3 with the following rewritten 
paragraph: 

In operation, the [Window Controll window controller 520 receives the SOF, SO A, and 
EOA signals from the [Video-In Controllerl video-in controller 510. In addition, the [Window 
Controller 5 10] window controller 560 receives, and/or has access to values indicating the X 
OFFSET, Y OFFSET, WIDTH, [AND]and HEIGHT values associated with Figure 6. These 
values can be provide in any number of manners, including inputs to the [Window 
Controller] window controller 520, or by accessing register locations. From the received values 
and signals, the [Window Controll window controller 520 generates a second set of control 
signals: Window control Start of Field (WSOF); Window control End of Field (WEOF); 
Window control End of Line (WEOL); Vertical Active (VACTIVE); and Horizontal Active 
(HACTIVE). These signals are further described with reference to the table below, and the 
relationship of the signal WSOF, WEOF, [AND]and WEOL are illustrated in Figure 8. 

Please replace the paragraph beginning at page 8, line 14 with the following rewritten 
paragraph: 
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rVIDEO-INI WINDOW CONTROL OPERATION FOR ZOOM VIDEO 



SIGNAL 



DESCRIPTION 



HACTIVE 



WSOF 



WEOF 



WEOL 



Pulse active when at first pixel of [Active Video] active video . 
Pulse active at last pixel of [Active Videol active video . 
Pulse active at end of each line of [Active Video] active video . 
Asserted when pixel count within [Width] WIDTH. 



VACTIVE 



Asserted when line count is with in HEIGHT. 



Please replace the paragraph beginning at page 8, line 24 with the following rewritten 
paragraph: 

The signal WSOF (Window control Start of Field) provides an asserted pulse when the 
first pixel of the [Active Video] active video 620 is encountered. The first pixel location can be 
determined by comparing the X OFFSET and Y OFFSET values to the current pixel and line 
numbers, which are maintained by the system. For example, in one implementation, the Y 
OFFSET represents the first line of [Active Video] active video 620, while the X OFFSET 
represents the first pixel of [Active Video] active video 620 within a line. This is represented in 
Figure 8, where the signal WSOF is active at the same time as the clock pulse labeled L. The 
clock pulse L represents the time at which the first pixel of the [Active Video 640] active video 
620 is available. 

Please replace the paragraph beginning at page 9, line 3 with the following rewritten 
paragraph: 

The signal WEOF provides an asserted pulse when the last pixel of the [Active 
Video] active video 620 is encountered. The last pixel location can be determined by comparing 
the sum of the WIDTH and X OFFSET values to the current pixel number, and comparing the 
sum of the HEIGHT and the Y OFFSET values to the line number. For example, in one 
implementation, the X OFFSET plus the WIDTH less one indicates the last bit of [Active]active 
video 620 associated with a line. Likewise, Y OFFSET plus the HEIGHT less one indicates the 
last line of [Active Videol active video 620. Therefore, by monitoring these values, the WEOF 
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signal can provide an asserted pulse when both the last line and pixel of an [Active Videol active 
video 620 region is encountered. This is illustrated in Figure 8, where the signal WEOF is active 
at a time in conjunction with the clock pulse labeled N. The clock pulse N represents the time at 
which the last pixel of the [Active Video 640] active video 620 is available. 

Please replace the paragraph beginning at page 9, line 14 with the following rewritten 
paragraph: 

The signal WEOL provides an asserted pulse when the last pixel of a line of [Active 
Videol active video 620 is encountered. The last pixel of a line can be determined by comparing 
the sum of the WIDTH and X OFFSET values to the current pixel number. For example, in one 
implementation, the X OFFSET plus the WIDTH minus one represents the last bit of a line of 
[Active Videol active video 620. This number can be compared to the current pixel number to 
determine whether the end of line has occurred. WEOL is represented in Figure 8, where the 
signal WEOL is active at a time in conjunction with the clock pulses labeled M and N. The 
clock pulses M and N represents the time at which the last pixel of a line of data is available. 

Please replace the paragraph beginning at page 9, line 22 with the following rewritten 
paragraph: 

The signal HACTIVE is asserted when the current pixel location is within the WIDTH 
region. Note that a pixel does not have to be in the [Active Videol active video 620 in order for 
HACTIVE to be asserted. This allows for an embodiment whereby only the pixel number is 
monitored and compared to the values associated with the WIDTH of the [Active Videol active 
video 620. Likewise, the VACTIVE signal is asserted when the current line number is within the 
HEIGHT region indicated in Figure 6. 

Please replace the paragraph beginning at page 9, line 28 with the following rewritten 
paragraph: 

It will be understood by one skilled in the art, that the exact time at which the [Window 
Controller 510] window controller 520 provides a given control signal can vary depending upon 
specific embodiments. For example, the WEOL signal can be asserted in conjunction with the 
last pixel, or after the last pixel. 
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Please replace the paragraph beginning at page 10, line 4 with the following rewritten 
paragraph: 

Referring to Figure 5, the signals generated by the [Window Controller 5 10] window 
controller 520 are used by the [Packer 640] packer 540 and the [Address Generator 63 01 address 
generator 530 to provide data and [address] addresses to the buffer. In one embodiment, the 
[Packer] packer 640 receives 8-bit bytes of data, and combines them to form larger data words 
labeled VIDEO DATA. For example, the VIDEO DATA signal can comprise 32, 64, or 128 bit 
words of video data. The width of VIDEO DATA can be fixed or programmable. The 
DACTIVE, HACTIVE, and VACTIVE signals qualify the VDATA received by the [Packer 
640 backer 540 . 

Please replace the paragraph beginning at page 10, line 9 with the following rewritten 
paragraph: 

For ZOOM VIDEO, DACTIVE is always asserted. Therefore, the [Packer 640]packer 
540 uses the HACTIVE and VACTIVE data to qualify VDATA. For example, when both 
rDACTIVEI HACTIVE and VACTIVE are asserted, the data value received on VDATA is 
within the [ACTIVE VIDEO] active video 620, and will be included by the [Packer 640] packer 
540 within the VIDEO DATA. If either of rDACTIVEI HACTIVE and VACTIVE are inactive, 
the data value received on VDATA is not within the [ACTIVE VIDEO] active video , and will 
[be] not be included by the [Packer 640] packer 540 as part of the VIDEO DATA. 

Please replace the paragraph beginning at page 10, line 15 with the following rewritten 
paragraph: 

The described embodiment for receiving ZOOM VIDEO provides for an efficient means 
to receive only a desired portion of [video data] VIDEO DATA , however, the data received needs 
be readily associated with a specific line and a pixel in order to determine where the [ACTIVE 
VIDEO] active video resides. In contrast, DVB data is compressed, and visibility as to the line 
and pixel locations not readily available without decompression of the data first occurring. In 
specific embodiments, it is desirable to perform such decompression of the data first occurring. 
In specific embodiments, it is desirable to perform such decompression by other parts of the 
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system, or at least to store the compressed data in other parts of the system. Therefore, one 
embodiment of the present invention further allows compressed data, such as DVB [transport 
steaml TRANSPORT STEAM data, to be buffered within the [Graphics Memory! graphics 
memory 330 of Figure 3. 

Please replace the paragraph beginning at page 10, line 25 with the following rewritten 
paragraph: 

Figure 9 illustrates a timing diagram representing signals associated with the 
TRANSPORT STREAM of Figure 2. The TRANSPORT STREAM includes a signal labeled 
TCK, which provides one clock pulse to qualify each byte of data.[.] A synchronization 
(SYNCH) signal indicates the beginning of a new line or packet of information. In addition, a 
data valid signal (D VALID) indicates when the packet data being transmitted is valid. 

Please replace the paragraph beginning at page 11, line 3 with the following rewritten 
paragraph: 

In response to the TRANSPORT STREAM, the [Video-In Controller 5101 video-in 
controller 520 drives the signals SOF, SOA, EOA, DACTIVE [ANDjand VDATA. The manner 
in which these signals are generated is different for a TRANSPORT STREAM than for the 
ZOOM VIDEO previously discussed. The table below indicates the operation of the [Window 
Controller 5 101 window controller 520 for TRANSPORT STREAM reception. 

Please replace the paragraph beginning at page 1 1 , line 9 with the following rewritten 
paragraph: 
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OPERATION FOR RECEPTION OF A TRANSPORT STREAM 



VIDEO-IN 

SIGNAL DESCRIPTION 



SOF Pulse active to indicate the first byte of a [transport 

stream] TRANSPORT STREAM packet to be stored in 
buffer. 

SOA Pulse active to indicate the first byte of a [transport 

streaml TRANSPORT STREAM packet. 
EOA Pulse active to indicate the last byte of a [transport 

streamj TRANSPORT STREAM packet. 
DACTIVE Asserted to indicate invalid bytes as indicated by DVALID. 

VDATA Data from TRANSPORT STREAM. 

Please replace the paragraph beginning at page 1 1, line 20 with the following rewritten 
paragraph: 

During reception of the TRANSPORT STREAM, the SOF signal provides an asserted 
pulse to indicate that the first byte to be stored in the [Graphics] graphics memory 330 is present. 
In one embodiment, the [Video-In Controller] video-in controller 5 1 0 will use a counter to keep 
track of the number of lines and bytes of compressed data provided to the [Window Controller 
5 1 0] window controller 520 . When the number of lines sent to the [Window Controller 
5 10] window controller 520 exceeds the number of lines available in the [Graphics 
Memory] graphics memory 330, the SOF is pulsed again to indicate a new first byte to be stored 
in the graphics memory. The SOF signal of Figure 9 illustrates two pulses. The first pulse 
corresponds to TCK 1, which is associated with the first data byte to be stored in the 
[Graphics] graphics memory 330. The second SOF pulse occurs on the first TCK after line N has 
been transmitted, where N is the total number of lines to be stored in the [Graphics] graphics 
memory 330. Note that in Figure 9, the number of bytes in a line of video memory is [88] 138. 
Coincidental!^ this is the same number of bytes that are in a fDATAI TRANS PORT STREAM 
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packet. In other embodiments, the line size is different than the packet size, such that a line of 
video memory will not necessarily contain an integer number of packets. 

Please replace the paragraph beginning at page 12, line 5 with the following rewritten 
paragraph: 

Note that the [Graphics Memory] graphics memory 330 can have one or more buffer 
locations. Where multiple buffer locations are present, it is possible to switch between buffers 
when one buffer is full, and continue storing data without delay, or with minimal delay, in a 
second buffer. If only one frame buffer is available, and it becomes full, it will be necessary to 
write at least some of the [Graphics Memory] graphics memory 330 contents to system memory, 
or lose data by writing over the stored values. By using a dual ported [Graphics 
Memoryl graphics memory 330, it would be possible to buffer data and transmit it to the system 
simultaneously. In another embodiment, a single ported memory can also do the job, by 
interleaving between read and write operations. 

Please replace the paragraph beginning at page 12, line 13 with the following rewritten 
paragraph: 

The [Video-In Controller] video-in controller 5 1 0 signal SOA indicates that the first byte 
of a TRANSPORT STREAM packet is being transported. The SOA signal can be qualified by 
the TRANSPORT STREAM'S SYNCH signal. There are three such SOA pulsed indicated in 
Figure 9. 

Please replace the paragraph beginning at page 12, line 24 with the following rewritten 
paragraph: 

The signal DACTIVE indicates when the data presented to the [Packer 640] packer 540 is 
valid. As indicated in Figure 9, the signal DACTIVE will generally mirror the signal DVALID 
of the TRANSPORT STREAM. 

Please replace the paragraph beginning at page 13, line 1 with the following rewritten 
paragraph: 
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The [Window Control] window controller 520 receives the SOF, SOA, and EOA signals 
from the [Video-In Controllerl video-in controller 510 representing the TRANSPORT STREAM. 
In addition, the [Window Controller 5 10] window controller 520 receives, and/or has access to, 
values indicating the X OFFSET, Y OFFSET, WIDTH, [AND]and HEIGHT values associated 
with Figure 6. For TRANSPORT STREAM reception, the X OFFSET [ANDjand Y OFFSET 
will generally be zero, the [width] WIDTH will be number of bytes in the TRANSPORT 
STREAM, and the HEIGHT will indicate the number of lines to be stored in the [Graphics 
Memory] graphics memory 330. From the received values and signals, the [Window Control 
5 10] window controller 520 generates the signals: Window control Start of Field (WSOF); 
Window control End of Field (WEOF); Window control End of Line (WEOL); Vertical Active 
(V ACTIVE); and Horizontal Active (HACTIVE). These signals are further described with 
reference to the table below. 

Please replace the paragraph beginning at page 13, line 1 1 with the following rewritten 
paragraph: 

WINDOW CONTROL OPERATION FOR TRANSPORT STREAM DATA 
SIGNAL DESCRIPTION 



WSOF Pulse qualified to SYNCH signal and counter. 

WEOL Pulse qualified to EOA. 

WEOF Pulse qualified to SOF and EOA. 

HACTIVE Assertion qualified to SOA and EOA when pixel count within 

rWidthl WIDTH . 

VACTIVE Asserted when between SOA pulse and EOA pulse 

HACTIVE Asserted when between SOF pulse and WEOF. 



Please replace the paragraph beginning at page 13, line 26 with the following rewritten 
paragraph: 
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The signal WSOF signal provides an asserted pulse to indicate the first byte to be stored 
within a buffer of the [Graphics Memory] graphics memory 330 buffer. For a specific 
embodiment, where the [Video-In Controllerl video-in controller 510 monitors and maintains the 
number of lines being written, the WSOF signal for a TRANSPORT STREAM will be 
analogous to the SOF signal generated by the [Video-In Controllerl video-in controller 510 . 

Please replace the paragraph beginning at page 14, line 3 with the following rewritten 
paragraph: 

The signal [WSOF] WEOF signal provides an asserted pulse to indicate the last byte to be 
stored in the current buffer location of the [Graphics Memory] graphics memory 330. The 
[Window Controller 5 10] window controller 520 generates the [WSOF] WEOF signal by 
comparing the number of EOA signal received since SOF was active, and comparing this 
number to the provided HEIGHT value, by setting the Y OFFSET to zero, and the HEIGHT 
value to the number of lines in the [Graphics Memory] graphics memory 330, it is possible for 
the [Window Controller 5 10] window controller 520 to generate the correct WEOF pulse without 
additional hardware. 

Please replace the paragraph beginning at page 14, line 9 with the following rewritten 
paragraph: 

The signal HACTIVE is asserted when the current byte location is within the WIDTH 
region which is set to the number of bytes in a packet (188 bytes). [6.] 

Please replace the paragraph beginning at page 14, line 1 1 with the following rewritten 
paragraph: 

The signal VACTIVE is asserted when the current data being received is to be stored [be 
stored] in the current line of the buffer. 

Please replace the paragraph beginning at page 14, line 13 with the following rewritten 
paragraph: 

The [Packer 640] packer 540 provides a signal labeled ADDR GEN REQ, which indicates 
when a line of data is ready to be stored in the [Graphics Memory] graphics memory 330. The 
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[Graphics Memory] graphics memory 330 address and control information, is provided to the 
[Graphics Memory] graphics memory 330 by the [Address Generator] address generator 630 
when ADDR GEN REQ is active. 

Please replace the paragraph beginning at page 14, line 25 with the following rewritten 
paragraph: 

An error signal can also be incorporated into the transport stream[ capture]. When an 
error signal is received, a specific code can be generated and written with the data stream. 
Subsequent systems can be notified that an error occurred by monitoring the data and 
[react] reacting accordingly. 

Please replace the paragraph beginning at page 15, line 1 with the following rewritten 
paragraph: 

In this manner, compressed and [uncompress] uncompressed data can be stored in the 
frame buffer represented by [Graphics Memory] graphics memory 330. Once an entire frame of 
data is stored in the [Graphics Memory] graphics memory 330 the data can be written to system 
memory, or it can be decompressed by the [Graphics Engine] graphics engine 320. 

Please replace the paragraph beginning at page 15, line 5 with the following rewritten 
paragraph: 

By having the [Video-In Controller] video-in controller 510 generate the SOF, SOA, 
EOA, DACTIVE, and VDATA in the manner indicated, it is possible to use much of the same 
hardware to implement a storage apparatus for both compressed and uncompressed video. 

Please replace the paragraph beginning at page 15, line 8 with the following rewritten 
paragraph: 

Figure 1 1 illustrates a method in accordance with the present invention. Generally, the 
method of Figure 1 1 has been discussed with respect to the specific system herein. At step 1101, 
a determination is made whether a first or second type of video data is to be received. 
Specifically, the first type of data represents TRANSPORT STREAM data as indicated in step 
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1 102. The second type of data represents a digital video stream different from a TRANSPORT 
STREAM, such as the ZOOM VIDEO signal discussed herein, as indicated at step 1 103. 

Please replace the paragraph beginning at page 15, line 14 with the following rewritten 
paragraph: 

At steps 1 102 and 1 103 the system is configured for either a TRANSPORT STREAM or 
a different digital video stream,, respectively. As discussed with respect to TRANSPORT 
STREAM and ZOOM [Video]VIDEO herein, these configurations indicate how a video 
controller will generates its output signals. 

Please replace the paragraph beginning at page 15, line 18 with the following rewritten 
paragraph: 

At step 1 104, a secondary set of control signals is generated from the received data 
stream. This corresponds to the [Video-In Controller] video-in controller 5 1 0 generating signals 
SOF, SOA, EOA, DACTIVE, AND VDATA, as discussed herein. 

Please replace the paragraph beginning at page 15, line 21 with the following rewritten 
paragraph: 

At step 1 105, at least a portion of the data stream is stored. Step 1 105 corresponds to the 
[Window Controller 510 , Packer 6401 window controller 520, packer 540 , and [Address 
Generator] address generator 530 working together as a data storage controller to store words of 
data in a buffer associated with [Graphics Memory] graphics memory 330. These words of data 
will contain at least a portion of the data received by the [Video-In Controller] video-in controller 
510 in the manner discussed herein. 

Please replace the paragraph beginning at page 15, line 26 with the following rewritten 
paragraph: 

At step 1 106, the information stored in the [Graphics Memory] graphics memory 330 is 
written to a system bus via the PCI [Interface] interface of [figure]Figure 3. 
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Please replace the paragraph beginning at page 16, line 1 with the following rewritten 
paragraph: 

The present invention has been described with reference to specific embodiment. One of 
ordinary skill in the art will recognize that other [embodimentj embodiments may exist. For 
example, the data storage described herein has [bee]been described with reference to using 
SOF/EOF/SOA/EOA video fields to store [transport streamJ TRANSPORT STREAM data. In a 
similar manner, fields such as Start of VBI and End of VBI could be used to indicate when to 
store the transport stream data. Such an implementation would require the [Window 
Controller] window controller 520 to provide indicators when VBI data is active and should be 
stored. By indicating the VBI data had the same number of lines of the buffer associated with 
the [Graphics Memory] graphics memory 330, the [transport stream] TRANSPORT STREAM 
data can be stored. 

Please replace the paragraph beginning at page 16, line 9 with the following rewritten 
paragraph: 

Another variation would allow the [transport streamJ TRANSPORT STREAM data to be 
stored in the buffer in a compressed form only when it is of a desired type of data. For example, 
the headers of the [transport stream] TRANSPORT STREAM can be [monitor]monitored to 
allow only a specific type of data, such as video or audio, to be buffered. 

Please replace the paragraph beginning at page 16, line 13 with the following rewritten 
paragraph: 

It should be further understood that specific functions and steps described may actually 
be implemented in hardware and/or in software. For example, the signal generation performed 
by the [Window Controller] window controller 520 can be performed by a hardware engine, 
firmware[,] such as in microcode[,] executed on the processing engine[,] or it may even be 
performed fully in software. In general, such functions can be performed in a processing module 
that may be a single processing device or a plurality of processing devices. Such a processing 
device may be a microprocessor, microcontroller, digital signal processor, microcomputer, 
portion of the central processing unit, state machine, logic circuitry, and/or any device that 
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manipulates signals (e.g., analog or digital) based on operational instructions. The memory may 
be a single memory device or a plurality of memory devices. Such a memory device may be a 
read-only memory, random access memory, floppy disk memory, magnetic tape memory, 
erasable memory, portion of system memory, and/or any device that stores operational 
instructions in a digital format. Note that when the processing module implements one or more 
of its functions via a state machine or logic circuitry, the memory storing the corresponding 
operational instructions is embedded within the circuitry comprising the state machine and/or 
logic circuitry. 

Please replace the paragraph beginning at page 16, line 28 with the following rewritten 
paragraph: 

The specific embodiments of the present invention disclosed herein are advantageous in 
that [transport streaml TRANSPORT STREAM data can be buffered in a portion of memory 
normally used by the [Video] video graphics adapter. Furthermore, the amount of overhead 
needed to store the [transport stream] TRANSPORT STREAM data is minimal because the 
system hardware/firmware/software is largely in place to handle the data. This is an advantage 
over other prior art embodiments which had dedicated hardware to merely convert [transport 
streaml TRANSPORT STREAM data into a useful format before be received by a VGA 
controller. By allowing transport stream data to be received directly by the VGA controller, cost 
savings and efficiencies are gained. In addition, variations of the specific embodiments are 
anticipated. For example, the uncompressed video may be digitized NTSC/PAL/SECAM signals 
as well. 

Please replace the paragraph beginning at page 21, line 1 with the following rewritten 
paragraph: 

A method and apparatus for storing a compressed video stream or an uncompressed video 
stream is disclosed. The uncompressed video stream may be [Zoom Video"| ZOOM VIDEO data. 
The compressed video stream may be a [transport streaml TRANSPORT STREAM data from a 
High Definition [television"| Television (HDTV) broadcast. A [Video Graphics Adapter]vkleo 
graphics adapter is configured to properly receive one of the two types of video data. The 
received data and control signals are monitored to provide a second set of control of data signal 
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which are used by a packer and an window control to provide data of a predetermined width and 
control to an address generator. The data is buffered within a graphics memory such as a frame 
buffer. The graphics memory can be written to system memory when full, or accessed by the 
system memory controller during the fill operation if a multi-ported memory is used. 

In the Claims : 

Please cancel Claim 1 without prejudice. 

Please amend Claims 2, 4-7, 10, 14-17 and 21 and add new Claims 22 and 23 to read as 
follows: 

2. (Amended) The system of Claim [1]22 further comprising: 

a memory having a first port coupled to the [second output port] output video data port of 
the [transport stream interface,] data storage controller and a second port coupled to the address 
port of the data storage controller [and a third port coupled to the control port of the data storage 
controller]. 

4. (Amended) The system of Claim 2 further comprising: 

a system bus interface having a first port coupled to a [fourth]third port of the memory, 
and a second port coupled to a [fifth] fourth port of the memory. 

5. (Amended) The system of Claim 4, wherein the [fourthjthird port of the memory is 
substantially the same as the second port of the memory. 

6. (Amended) The system of Claim [1]22, wherein the digital video transport stream is a 
digital video broadcast transport stream. 

7. (Amended) The system of Claim 6, wherein the control signals of the digital video 
transport stream include a clock signal, a synchronization signal, and a data valid signal[. It can 
also contain an error signal, indicating there is an error in the transport stream]. 
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10. (Amended) The system of Claim 9, wherein the set of control signals of the 
[transport stream interface controll data storage controller includes a valid vertical blanking 
interval signal to indicate when data on the [second output port of the transport stream interface 
control] output video data port of the data storage controller is present during a vertical blanking 
interval. 

14. (Amended) A method of receiving video graphics data, the method comprising the 
steps of; 

receiving a transport stream associated with a digital video broadcast signal, the transport 
stream having data signals and control signals; 

generating a secondary set of [controls]control signals from the transport stream's control 

signals; 

storing at least a portion of the transport stream data signals in a memory buffer 
controlled by the secondary set of control signals; and 

sending the contents of the memory buffer to a system bus. 

15. (Amended) The method of Claim 14, further comprising: 

wherein the steps of receivings generating and storing occur when in a first mode of 
operation; 

during a second mode of operation, performing the steps of: 

receiving a digital video signal having [a] data signals and [a] control signals, 
wherein the digital video signal is of a different type than the transport stream; 

generating the secondary set of [controls] control signals from the digital video 
signal's control signals; and 

storing at least a portion of the digital video signal in the memory buffer based on 
the secondary set of control signals. 
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16. (Amended) The method of Claim 15, wherein the video signal is a [Zoom 
Video] zoom video signal. 

17. (Amended) The method of Claim 14, wherein the memory buffer is a frame 
buffer. [.] 

21 . (Amended) A method of storing video data, the method comprising the steps of: 

in a first mode of operation storing pixel information in a frame buffer of a video 
adapter, wherein one line of frame buffer memory is representative of one line of a video image 
to be displayed; 

in a second mode of operation, storing compressed transport stream data in the frame 
buffer, wherein one line of frame buffer memory is representative of one transport stream packet. 

22. (New) A video graphics system comprising: 

a transport stream port to receive a digital video transport stream, the digital video 
transport stream including a data stream and control signals; 

a transport stream interface control having an input coupled to the transport stream port, 
and having a first output port to provide a set of control signals, and a second output port to 
provide a video graphics data; and 

the data storage controller having a first input port coupled to the first output port of the 
transport stream interface control to accept the set of control signals of the transport stream 
interface control a second input port coupled to a second output port of a transport stream 
interface control to accept video graphics data, an output address port to provide an address 
value, an output video data port to provide video data, and at least one pair of a plurality of 
internal control ports to communicate control signals within the data storage controller. 

23. (New) The system of Claim 7, wherein the control signals of the digital video 
transport stream further include an error signal, indicating there is an error in the transport 
stream. 
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